fix(media-uploads): copy media upload files when cloning an activity; freeze modern-format upload paths - #643

ref: https://app.clickup.com/t/9014802374/86bchyjfg

Problem

• SummitService::cloneEvent cloned PresentationMediaUpload records but not their files. The clone's path is built from the clone's presentation ID (always legacy format), so every cloned upload pointed at a path with no file. Seen in prod on OCP Global 2026 (activity 10346 cloned from 10177).
• A modern-format upload's path is re-derived from the current title slug in getPath(), so renaming an activity (or changing the summit slug) moved the path away from the stored file. Legacy-format paths use only IDs and were unaffected.

Fix

• Rename: new nullable PresentationMediaUpload.FrozenPathSegment. getPath() uses it for modern-format rows; output is byte-identical for every row where it is null. Version20261014120000 adds the column (Builder), Version20261014120001 backfills the LegacyPathFormat = 0 rows with the segment getPath() produces today (same empty-title rule as generateSlug()).
• Clone: after cloneEvent commits, it queues one CopyClonedMediaUploadFilesJob per cloned upload (JobDispatcher::withDbFallback). The job is a thin delegate to SummitService::copyClonedMediaUploadFiles (and removeUncopiedClonedMediaUpload from failed()). The logic lives on SummitService rather than PresentationService because it shares a storage lock with processPendingMediaUploads, which lives there. The copy streams each enabled storage leg from the original's path to the clone's (readStream -> saveFromStream, overwriting every attempt), skips a leg the original does not have, and retries (8 tries over about 23 minutes, timeout 1200 s, below retry_after). It copies the filename the clone was queued with, so a later re-upload of the original under a new name does not change what the clone gets.
• The job never writes to or deletes a clone upload staff have re-uploaded since (filename changed, or any PendingMediaUpload row for it), and retries while a re-upload of the original is still in flight.
• A per-storage-location Redis lock (ILockManagerService, SummitService::mediaUploadStorageLockName = media_upload_storage.{presentation_id}.{sha1(filename)}.lock) is shared by the job and processPendingMediaUploads. The job holds the lock of both the clone's location and the original's, so a staff upload landing mid-copy is written after the copy, never overwritten by it, and an original is never read while it is being written. The processor skips a locked row untouched and picks it up on the next minute's run. If the lock store itself is unreachable, the processor keeps processing without the lock; a copy waits and retries instead.
• The job carries both presentation IDs, takes its locks before reading the database, and reads both upload records fresh under them. If staff delete the clone's upload while the copy runs, the copied files are marked deleted.
• If every attempt fails (including a final-attempt timeout, which Laravel handles in-process), the cleanup removes the clone's upload record before marking its files deleted, so the clone never points at a missing file. Staff then re-upload on the clone.

Tests

• New: CopyClonedMediaUploadFilesJobTest (26), PresentationMediaUploadPathTest (7), FrozenPathSegmentBackfillMigrationTest (4).
• Updated: SummitServiceTest (clone queues the copy and the copy lands; dispatch failure; processor skips a locked upload), ProcessPendingMediaUploadsTest (lock dependency; locked row untouched; lock store unavailable; release failure).
• push.yml: adds the MigrationUnitTests shard and the new root test file to the PresentationMediaUploads shard.
• Unchanged by this branch and failing identically on main locally: the OAuth2PresentationApiTest + OAuth2SummitEventsApiTest pair (17 failures, 1 error), SponsorUserPermissionTrackingTest (2), and 3 in tests/Unit/Entities.

Deploy notes

• This changes the pending upload processor.
• Squash-merge (one intermediate commit has a red unit test).
• Two migrations run on the image build. Afterwards SELECT COUNT(*) FROM PresentationMediaUpload WHERE LegacyPathFormat = 0 AND FrozenPathSegment IS NULL should be 0. Checked against prod on Nov 13: 221 rows are in scope and the longest title is 113 characters, well inside the 1024-character column.
• Smoke test on a non-show summit: clone an activity with a deck and confirm the file lands on both storage legs (Spaces and Dropbox). CI covers the Local driver only.
• Expect LockManagerService ... MAX RETRIES ERROR lines while a clone copy holds a lock the processor wants, or while one copy waits on another (for example a clone of a clone). They are lock misses, not failures: the processor picks the row up on its next run and the copy retries.
• A copy that cannot proceed retries for about 23 minutes before its cleanup removes the clone's upload. CopyClonedMediaUploadFilesJob::failed in the log is the signal that staff need to re-upload on the clone.
• If Redis is unreachable, the processor logs lock store unavailable, processing without the storage lock (WARNING) for each row and keeps writing staff uploads. Clone copies do not run without the lock. If the outage outlasts a copy's retries, its cleanup cannot take the lock either: it keeps the clone's upload and logs could not take the storage lock to remove clone media upload (ERROR), and that upload needs a delete or re-upload on the clone.

Known limits

• A modern-format row whose title changed before the backfill is frozen at the current slug; those rows (2020, summits 8 and 12) were already broken.
• Between the clone request and the copy finishing, the clone's upload briefly has no file.
• A clone of a clone made while the first clone's copy is between retries can copy a first clone that is not fully filled yet.
• A worker killed outright mid-copy (not a timeout) leaves its locks to expire after 1300 s, which delays a same-name upload at either location by up to about 22 minutes.